IRIX 6.5 Complementary Applications 2004 February/SGI IRIX 6.5 Complementary Applications 2004 February.iso/relnotes/tooltalk_dev/ch3.z/ch3

Text File | 2004-01-09 | 8.7 KB | 199 lines

                                  - 1 -



       3.  _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s

       This chapter describes the known problems with the 1.4
       version of ToolTalk.

          +o The Object Types (otypes) and the related ToolTalk
            enhanced shell commands (_t_t_c_o_p_y, _t_t_m_v, etc.) should be
            used for prototyping systems only.

          +o If you see the message:

            WWWWaaaarrrrnnnniiiinnnngggg:::: ccccoooouuuullllddddnnnn''''tttt aaaaccccqqqquuuuiiiirrrreeee XXXX sssseeeelllleeeeccccttttiiiioooonnnn

            it is possible that ToolTalk has started two
            ttsessions.  The older of these sessions is not active.
            You can kill the inactive session with the IRIX _k_i_l_l
            command.

          +o If the default ttsession is killed, it leaves a
            property on the X root window defining that session.
            To locate the property, type:

            xxxxpppprrrroooopppp ----rrrrooooooootttt |||| ffffggggrrrreeeepppp ____SSSSUUUUNNNN____TTTTTTTT____SSSSEEEESSSSSSSSIIIIOOOONNNN

            Or, if you are running in a ClearCase _v_i_e_w, type:

            xxxxpppprrrroooopppp ----rrrrooooooootttt |||| ffffggggrrrreeeepppp ____SSSSGGGGIIII____TTTTTTTT____SSSSEEEESSSSSSSSIIIIOOOONNNN____<_v_i_e_w__n_a_m_e>

            To remove the property, type:

            xxxxpppprrrroooopppp ----rrrrooooooootttt ----rrrreeeemmmmoooovvvveeee <_p_r_o_p_e_r_t_y__n_a_m_e>































                                  - 2 -



          +o If you have a ptype defined, but the program that is
            autostarted on behalf of that ptype does not declare
            itself to be that ptype, ToolTalk continues to start
            the same program.  If this happens, kill the _t_t_s_e_s_s_i_o_n
            process and the many instances of the autostarted
            program, and fix your program to declare itself
            properly.  For example, in the example program
            _t_t__s_g_i__s_e_r_v_i_c_e, tt_ptype_declare is called before
            tt_session_join.  This also points out the importance
            of declaring the ptype _b_e_f_o_r_e joining the session.

          +o By default, ToolTalk tries to connect to the X display
            defined by the DISPLAY environment variable to
            determine what ttsession to join.  The call to
            XOpenDisplay (which connects to the X display) can fail
            in several ways:

               - If DISPLAY is set to a machine that is running
                 _P_a_n_d_o_r_a, the Silicon Graphics (SGI) login, the SGI
                 _X_l_i_b prints out the following warning:

                 XXXXlllliiiibbbb:::: ccccoooonnnnnnnneeeeccccttttiiiioooonnnn ttttoooo """"<<<<hhhhoooossssttttnnnnaaaammmmeeee>>>>::::0000....0000"""" rrrreeeeffffuuuusssseeeedddd bbbbyyyy sssseeeerrrrvvvveeeerrrr
                 XXXXlllliiiibbbb:::: CCCClllliiiieeeennnntttt iiiissss nnnnooootttt aaaauuuutttthhhhoooorrrriiiizzzzeeeedddd ttttoooo ccccoooonnnnnnnneeeecccctttt ttttoooo SSSSeeeerrrrvvvveeeerrrr

                 There is currently no way to suppress this
                 warning.  Because you probably do not want to
                 connect to a message server on this machine in
                 this case, set your DISPLAY environment variable
                 to the machine running the desired ttsession.

               - If DISPLAY is set to a machine that is running XDM
                 (X Display Manager) as the login, a call to
                 XOpenDisplay hangs and might eventually return
                 with the following message:

                  XXXXIIIIOOOO:::: ffffaaaattttaaaallll IIIIOOOO eeeerrrrrrrroooorrrr 33332222 ((((BBBBrrrrooookkkkeeeennnn ppppiiiippppeeee)))) oooonnnn XXXX sssseeeerrrrvvvveeeerrrr
                       """"((((nnnnuuuullllllll))))"""" aaaafffftttteeeerrrr 0000 rrrreeeeqqqquuuueeeessssttttssss ((((0000 kkkknnnnoooowwwwnnnn pppprrrroooocccceeeesssssssseeeedddd))))
                       wwwwiiiitttthhhh 0000 eeeevvvveeeennnnttttssss rrrreeeemmmmaaaaiiiinnnniiiinnnngggg....  TTTThhhheeee ccccoooonnnnnnnneeeeccccttttiiiioooonnnn wwwwaaaassss
                       pppprrrroooobbbbaaaabbbbllllyyyy bbbbrrrrooookkkkeeeennnn bbbbyyyy aaaa sssseeeerrrrvvvveeeerrrr sssshhhhuuuuttttddddoooowwwwnnnn oooorrrr KKKKiiiillllllllCCCClllliiiieeeennnntttt....

                 Once again, you can set DISPLAY to avoid this
                 condition.  If you are programming to handle this
                 condition, one solution for detection without
                 hanging is to set a timer surrounding the call to
                 tt_open (which calls XOpenDisplay).  You can do
                 this by setting a signal handler for the SIGALRM
                 signal, and setting the alarm for how long you
                 will give XOpenDisplay to connect or fail.














                                  - 3 -



               - A third possible failure is if the DISPLAY is set
                 to a machine (server) that is not running the X
                 server (Xsgi).  In this case, the call to
                 XOpenDisplay returns nil but takes a long time.
                 Again, it makes sense to set the DISPLAY
                 appropriately.

          +o If two clients require the same ptype service, but have
            joined different files, simultaneous autostart handles
            both requests successfully, but the second client
            receives a reply with state TT_FAILED. This happens
            when both clients have scope=TT_FILE_IN_SESSION.

          +o SunSoft ToolTalk sets the SIGPIPE signal handler for
            clients unconditionally to SIG_IGN. This overrides any
            previous setting for this signal handler.  In SGI
            ToolTalk, if the SIGPIPE signal handler of the client
            is set to anything other than SIG_DFL (default), it is
            left unchanged.  Set your signal handlers before
            calling ToolTalk.

          +o Point-to-point notices that do not have a handler set
            for them are ignored, instead of an error code being
            returned from tt_message_send().  The workaround is to
            always name your recipient (via
            tt_message_handler_set()) when you send a point-to-
            point (that is, TT_HANDLER) message. Because no error
            message is returned if you do not, make sure always
            name your recipient.

          +o If you create a message, then send it more than once,
            subsequent sends are not reliable. This is not supposed
            to work at all!  Do not send the same message more than
            once; create a new message each time.

          +o When tt_close is called, more than just the default
            proc ID is closed.  Other proc IDs obtained via earlier
            tt_open calls cause the TT_ERR_PROCID error when they
            are used.  The workaround is to call tt_open() right
            after calling tt_close(). That creates a new proc ID
            and causes it to be the default proc ID.  Then call
            tt_default_procid_set() to set the default proc ID to
            be one of your ``real'' proc IDs.  Note that this is
            relevant only if you are juggling multiple proc IDs in
            the same process, which is not the typical case.

          +o TT_ERR_OVERFLOW is not currently reported when
            thousands of queued messages are sent and never
            delivered.  The workaround is to make sure the receiver
            proceeds normally by calling tt_message_receive.